|
| Company / developer | Unisys |
|---|---|
| OS family | OS 2200 |
| Working state | Current |
| Source model | Proprietary software. Most source is available to clients under license. |
| Initial release | 1967 as Exec 8 |
| Latest stable release | CP13.0[1] / June 9, 2010 |
| Marketing target | Enterprise / Mainframes |
| Update method | Line number based packaged changes |
| Package manager | PRIMUS (internal), COMUS (client) |
| Supported platforms | Unisys ClearPath Dorado systems |
| Kernel type | Monolithic kernel (uniquely hardware-assisted) |
| Default user interface | Command line |
| License | Proprietary. Term license or pay for use (metered) licenses |
| Official website | Unisys eCommunity OS 2200 Products |
OS 2200 is the operating system currently used for the Unisys ClearPath Dorado family of mainframe systems. OS 2200 is a lineal descendant of Exec 8 for the UNIVAC 1108. The name Exec 8 was shorthand for “Executive System for the UNIVAC 1108.” The UNIVAC 1108 computer was announced in 1964 and delivered in late 1965. The first 1108 computers used Exec I and Exec II which had been developed for the UNIVAC 1107. However, UNIVAC planned to offer symmetric multiprocessor versions of the 1108 with up to 4 processors and the earlier operating systems (really basic monitor programs) weren’t designed for that. The specifications for Exec 8 were drawn up by December 1964 as a preliminary Programmers Reference Manual (user guide) and work began in May 1965.[2], [3]
Documentation and other information on current and past Unisys systems can be found on the Unisys public support website[note 1] and the Unisys eCommunity[note 2]
There were earlier 1100 systems going back to the 1101 in 1951, but the 1108 marked the introduction of the first 1100 Series computer designed for a modern operating system. Previous systems were all real-mode systems with no hardware support for protection and separation of programs and operating system. While there was support for multi-programming in previous software, it was limited to running one user job and multiple, known to be well-behaved, supporting functions such as card reader, printer, and card punch spoolers.
Along with the new hardware system came the introduction of an operating system known as Exec 8 (the Executive System for the UNIVAC 1108). Previous system software instantiations (Exec I, Exec II) are more properly known as monitor systems even though they did support limited multi-programming. Exec 8 was designed from the very beginning to be a multi-programming, multi-processing operating system since the 1108 was designed to have up to 4 CPUs. Memory size and cost and mass storage size and cost were the primary constraints. The predecessor systems were also heavily used for scientific computing, process control, message switching, and other real time functions. While the 1100 Series was envisioned as targeting a more general market, extreme real time processing was a primary requirement.[4]
When the UNIVAC 1110 was introduced in 1972, the operating system name was changed to OS 1100 to reflect its support for the wider range of systems. The name OS 1100 was retained until 1988 with the introduction of the Sperry 2200 Series as a follow on to the 1100 Series when its name was changed to OS 2200. Since that time, the 2200 Series became the Unisys ClearPath IX Series and then the Unisys ClearPath Dorado Series, but the operating system retained the OS 2200 name.
The company name and its product names also changed over time.[5] Engineering Research Associates (ERA) of Saint Paul was acquired by Remington Rand Corporation. Remington Rand also acquired the Eckert–Mauchly Computer Corporation of Philadelphia which was then building the UNIVAC computer. The two were combined into the UNIVAC division of Remington Rand under the direction of William Norris. William Norris had been one of the founders of ERA and later left Remington Rand to start Control Data Corporation. The UNIVAC division of Remington Rand Corporation became the UNIVAC division of Sperry Rand Corporation after Remington Rand merged with Sperry Corporation. In the 1970s Sperry Rand began a corporate identity program that changed its name to Sperry Corporation and all the division names to Sperry ___ so that the computer systems division became Sperry UNIVAC. Later the division names were dropped and everything simply became Sperry. The operating system is still referred to as “the Exec” by most Unisys and customer personnel.
In 1986 Burroughs and Sperry corporations merged to become Unisys (which some long time 2200 Series clients say stands for “UNIVAC Is Still Your Supplier”). The major mainframe products lines of both companies have continued in development including the MCP Operating System from Burroughs and OS 2200 from Sperry.
See Unisys 2200 Series system architecture for a description of the machine architecture and its relationship to the OS 2200 operating system.
Exec 8 was designed to run on systems that often only had 128K words (~512K bytes) and was focused on real time batch processing. While the earliest release levels did work in the 128KW (usually called 131K by UNIVAC), increasing function in subsequent releases made that untenable as it didn't leave enough space for programs of any useful size. The maximum memory capacity of an 1108 was 256KW (called 262KW or about 1MB) so efficient use of memory was probably the single most important constraint. The core memory of the time was also the single most expensive part of the system. Mass storage devices weren't much better. High speed storage consisted of drum memories that held 256KW (FH-432) to 2MW (FH-1782). The highest capacity mass storage was the FASTRAND drum which held 22MW or about 100MB.
With the memory constraints and the real time focus, the idea of having only a single copy of code loaded in memory for multiple uses was included as a requirement. Since the 1108 was a multi-processing system, the operating system was designed to be fully reentrant (thread safe in today’s terminology) and to use fine-grained locking to protect shared data during updates. The design included having compilers, utilities, and even user applications that might have multiple copies running concurrently written so that their code could be shared. This would require loading only one copy of the code in memory which saved both space and the time it took to load the code. Each use would get its own copy of the data.
A supporting idea in the hardware was that the memory was designed with two physical banks (cabinets) each with its own access paths. Thus a CPU could access both banks simultaneously. By loading the code into one bank and data into the other bank of memory, the average execution time of the instructions could be halved. So it was natural for this reason as well to separate code and data into different load entities. These were called banks (from the memory banks and because segment referred to a commonly used programming technique known as overlay segments).
Code that was going to be shared had to be thread safe which means it had to be read/execute only. Writing into the code stream was not allowed if it was going to be shared. While writing into the code stream was still a fairly common programming technique in 1967, 1100 Series users were encouraged not to do so simply because of the performance benefit. The security and reliability benefits were touted but not highly valued at that time by customers.
Exec 8 began as a real time operating system with early use for message switching, process control of simulators and missile firings, and general scientific and engineering work. It was primarily a batch processing system that allowed applications very fine control of processor priority for each thread (called activities). All processor switching was preemptive with higher priority threads gaining control of the processor currently running the lowest priority thread of any program. It was a multi-programming and multi-processing operating system with fully symmetric processor management. A test-and-set instruction built into the hardware allowed very efficient and fine-grained locking both within the OS and within multi-threaded applications.
In 1968 work began on adding time-sharing capability to Exec 8 and that was delivered with level 23 of Exec 8 in 1969. Time sharing (called Demand from “on demand”) provided identical capabilities to batch and real time processing. Everything that could be done in batch could be done in Demand mode. In Demand mode the job stream input and output were attached to a terminal handler rather than spool files. The same job control language (ECL – Executive Control Language) was used for both. A few years later some more specific time sharing capabilities were added to allow some of the ECL statements to be issued for immediate processing even while a program was running. At first these were just the statements to kill the program or redirect output to a file, but later all control statements related to files and devices were also allowed to be “immediate.”
In Exec 8 work is organized into jobs, called “runs,” which are scheduled based on their priority and need for specific resources such as tape reels or exclusive control of files. The control language ECL uses a syntax with the “@” as the control statement recognition symbol followed by the command or program name. That is then followed by a comma and option letters a space and then positional parameters that depend on the nature of the specific command. So a command to compile a C module would look like “@UC,opt source, object.” Input data for an application may be read from a file or be in line following the command that starts the application. All lines that do not have the leading “@” are presumed to be in-line data.
A transaction processing capability was developed in the late 1960s as a joint project with United Airlines and later refined in another joint project with Air Canada. This capability was fully integrated into the operating system in 1972 and became the basis of much of the future growth of the 1100 Series. Early users controlled communication lines directly from within their real time programs. Part of the development of transaction processing included a communication message system that managed the communication lines and presented messages to Exec 8 to be scheduled as transactions. This moved all the low level communication physical line management and protocols out of the applications and into the CMS 1100 application. CMS 1100 itself ran as a real time multi-threaded program with the privilege of acquiring control of communication lines and submitting transaction messages for scheduling. This led to the notions in Exec 8 that applications of any nature needed to be carefully controlled to ensure that they could not cause integrity issues. Security was certainly a concern, but in the early days system reliability and integrity were much larger issues. The system was still primarily batch and transaction processing and there was little chance that anyone could install unauthorized code on the system. CMS 1100 later added the capability to be the interface for Demand terminals as well as transaction terminals so that terminals could be used for both and the early terminal drivers could be removed from the Exec. CMS 1100 was later replaced by CPCOMM.
As of 2010 the OS 2200 release is level 48R6 (48.370.4). The internal system levels use a three-part number such as 21.92.42 (which was the first widely used production system although earlier releases were used in production at a number of sites). The first number part indicates the major level and indicates a new version of the Exec with all previous updates integrated into a new base version. This is an infrequent process and occurs at intervals of years. The second number part indicates versions of updates to the major level and often occurs several times per week. When a decision is made to freeze the feature content and prepare for release, the third part comes into play and indicates versions of the pre-release level as fixes and minor feature updates are applied. Concurrently with preparing a level for release, updates to the “mainline” continue as engineers integrate changes in preparation for a future release. For many years the official release level was the full three-part number. Later releases were named simply 44R1, 44R2, 45R1, and so on although the three-part number is still used internally.
The Exec contains all the code in the system that is allowed to run at the highest privilege levels. There are no mechanisms for other code to be promoted to those privilege levels.
The Exec is responsible for managing the system hardware, scheduling and managing work, and communicating with operators and administrators.
The Exec is at heart a real time, multi-threaded batch processing system. Everything has been built around that model. The Exec itself is largely structured as a real time program. Functions that are performed as Services in Windows or Daemons in Linux and UNIX are implemented as either activities within the Exec or as batch programs that are always running in the background.
Time-sharing (known as Demand from “on demand”) and transaction processing are implemented as special cases of batch. One result is that there are few restrictions on what a time-sharing user or transaction program can do. There are lots of warnings for writers of transaction programs that they will not be happy with performance if for example they call for a tape mount, but it is permitted.
The largest unit of work is the “Run.” This is taken from the factory “production run” terminology and generally equates to job or session on other systems. A Run is defined by its “run stream.” A run stream is a sequence of control statements that represent the steps to be taken. They may include file handling, program execution, and branches of control. A batch Run is typically stored as a file and is scheduled by a “Start” command from within another Run or by the operator. A time sharing Run is initiated by logging in from a time-sharing terminal and inputting the @RUN command. Often the @RUN statement and the second control statement (often @ADD or a program execution) are generated automatically based on the user profile. Security authorizations are validated based on the authenticated user-id and other information supplied on the Run control statement.
Transactions are a special case. There aren’t actually any control statements, but the internal data structures of a run are created. This enables the Exec to associate the same security, accounting, debugging, etc. mechanisms with transaction programs. Generally a security profile is cached in memory at the time the transaction user is authenticated and is copied from the user’s session data to the transaction run state when the transaction is scheduled. Because each transaction instance is essentially a Run, accounting, logging, and error handling are all encapsulated by the Run mechanism.
Batch jobs (Runs) are characterized by having a runstream (job control language statements) stored in a file. A batch job always contains an @RUN statement as the first record in the file. This statement gives the run a name (runid), defines priorities, and defines the maximum number of SUPS (Standard Units of Processing) the job is expected to use. The job is started from some other job with a @START control statement or by the operator via an ST keyin. The system may be configured to automatically issue @START statements for any number of jobs when it boots. These jobs serve the purpose of performing initialization, recovery, and background functions.
All of the fields on the @RUN statement may be overridden by corresponding fields on the @START statement. Except when the @START is executed by a privileged user, the userid and other security state are always taken from the run doing the @START.
There are two priority fields on the @RUN statement. One is used to specify the backlog priority. There are 26 backlog priority levels (A – Z). The Exec has a configured maximum number of open batch runs. When that level is reached, jobs are then selected from the backlog queues in priority order. Within a priority selection is usually FIFO. However, the Exec pre-scans the job control statements up to the first program execution looking for file names and reel numbers. If the job would immediately stall because some resources it needs are not available, it may be bypassed to start other jobs at the same priority level.
The second priority level defines an execution processor resource group. We’ll talk later more about how processor allocation is done, but higher execution group priorities typically get more processor time.
While the OS 2200 job control language does not support full programmability, it does allow dynamic additions of sequences of control language through an @ADD control statement. The file to be added may have been created by the same job immediately preceding adding it. The @ADD and most other control statements may also be submitted from within a running program via an API.[6] Additional programmability is available indirectly through the use of the Symbolic Stream Generator (SSG[7]). SSG is a programming language for manipulating and creating text files from input parameters and system information. It is used heavily for configuration management (make) processing and other functions where text images need to be created programmatically. The resulting output can be “@ADD”ed in the same run thus providing the indirectly programmable runstream.
Operator keyins are available to change both the backlog and execution priorities of runs. As all operator keyins are available by API to suitably privileged users, this can be automated or controlled by a remote administrator.
Deadline is a special case of batch. A deadline run looks just like any other batch run except that a deadline time is specified on the @RUN or @START control statement. The deadline time is used in conjunction with the maximum SUPS (time estimate) on the control statement. A deadline job runs at normal batch priorities unless or until it appears that it could miss its deadline time. Then the more the mismatch between time until the deadline and remaining SUPS, the higher the priority. While deadline can’t totally shut off transactions and has no effect on real time, it can effectively shut off most other processing in the system if necessary to achieve its goal.
OS 2200 time-sharing sessions are called demand runs. They use the same control language as batch runs with a few additions known as “immediate” control statements. Immediate control statements use the “@@” sentinel which indicates that they are to be executed immediately even if a program is running. While they can be used to create or assign files, the most important ones allow a demand user to error terminate a running program or even send it a signal.
Transactions execute as runs but without any stored or submitted control statements. Instead when a message is received from a session defined as a transaction session, it is scanned to determine the transaction queue on which it is to be placed. This is normally determined by the first characters of the message but user-written scanners may be added.[8]
The communication manager, which is capable of handling up to 250,000 active sessions, takes incoming transaction messages and passes them to the message queuing software. It can handle an unlimited number of queued messages using the message queuing architecture. A call is made to the Transaction Interface Package (TIP) APIs in the operating system to queue the transaction on the appropriate queuing point. Each queuing point identifies the priority and concurrency level of the work and the associated transaction program to be executed.
A transaction program scheduling tree allows the client to establish relative usage for groups of transaction programs. Concurrency limits avoid one type of work dominating the system to the exclusion of other work and avoid creating an over commitment of resources. Up to 4094 nodes may be created in the tree.
Priority (0 to 63) and concurrency level (1 to 512) specified for each transaction program.
The highest priority transaction is selected for scheduling except as limited by the concurrency policies in effect for its node and higher nodes.
Real time is not another type of run. Rather it is a set of priority levels which any activity may request. Real time is most typically used by long running batch programs, like the OS 2200 communications manager CPComm, but is not restricted to such.
There are 36 real time priority levels available by API for applications to use. The user and account must have the privilege to use real time priorities. It is up to the site to control how their applications use the priority levels. Real time priorities totally dominate all lower priorities so it’s quite possible for a misbehaved real time program to tie up one or more processors.
The real time priority applies to an individual activity (thread) so a program may have both real time and non-real time threads executing at the same time.
Once a run has been started, getting access to the processor controls its rate of progress. The heart of the Exec is the Dispatcher which manages all the processors.[9]
The Exec supports up to 4095 dispatching priorities although most sites define only a small subset of those. The two highest “priorities” aren’t switchable. They are recognition of certain types of processing that must be allowed to continue on the processor on which they started until they voluntarily give up control. Interrupt lockout occurs when an interrupt comes in or in a few special cases when other Exec code prevents all interrupts (in order to change some data that an interrupt handler may also access).
Interlock is used by interrupt post processing routines that either need to run on the same physical processor or simply should not be interrupted. The Dispatcher, I/O completions, and I/O initiation are some examples. All locks used by both of these priorities are spin locks as the only way they can be set by someone else is on another processor and the design requires that they only be set for very short instruction sequences.
High Exec priority is used by the operator keyin service and some other functions that may have to run even when a real time program has control. They are expected to use only very short amounts of time. If they need more time, they should queue the work to be processed by a Low Exec activity.
Real time activities have an unlimited processor quantum and run without switching unless interrupted by a higher priority real time activity or High Exec activity. Real Time activities are given control of any available processor that is running something of lower priority. Interrupts are sent between processors when necessary to ensure immediate availability. Real time is used by customers to fly missiles, run simulators, and other functions that require immediate response. OS 2200 has long guaranteed real time events get control of a processor within 50 microseconds.
Transaction priorities may be handled in two ways as defined by the site. They may be a sort of lower priority real time in that only the priority matters and the quantum size is essentially infinite. This is appropriate for very short-lived transactions such as airline reservations; if one loops due to a programming error, the Exec will terminate it when it reaches its very small configured maximum time. The other form allows the Exec to vary the priority within a range to optimize system resource usage. The approach gives higher priority and shorter time slices to programs that are I/O limited and progressively lower priorities but longer time slices to those that are computing. The Exec dynamically adjusts these priorities based on behavior as programs often behave both ways at different times. This approach is appropriate for longer running transactions like database queries or airline fare quotes.
Batch and demand always use dynamically adjusted priorities. Programs that are I/O limited or are in a conversation with a time-sharing user get higher priorities but short time slices. More compute-oriented programs get lower priorities and longer time slices.
The Exec has two additional mechanisms for optimizing dispatching. One is affinity-based dispatching. When possible the Exec will run an activity on the same processor that it was on the last time to get the greatest advantage of residual cache contents. If that isn’t possible it tries to keep the activity on the “nearest” processor from the standpoint of cache and memory access times. The second is a “fairness” policy mechanism. The site can define the relative percentage of resources to be allocated to each of transactions, demand and batch. Within transactions and batch there are priority groupings that can further indicate what percentage of their group’s time is to be allocated to the priority. This ensures that transactions cannot so dominate the system that no batch work gets done. Within the various priority groupings it ensures that some progress can be assured for each group (unless the group percentage is zero). These “fairness” algorithms only come into play when the processors are very busy, but OS 2200 systems often run with all processors at near 100% utilized.
OS 2200 supports several models for system performance management. Customers may purchase a certain fixed performance level, and the Exec will monitor processor usage to ensure that performance does not exceed that level. Customers can also purchase additional performance either temporarily or permanently up to the full capacity of the system if their workload increases or an emergency requires it.
More recently the system has added a metered usage capability. In this mode the full power of the system is always available to the customer (although they may administratively limit that). The usage is accumulated over a month and then the reported usage is submitted to Unisys billing. Depending on the specific contract terms the client may receive a bill for excess usage above some contracted baseline for the month or just a statement showing that the total contracted usage has been decremented. The first form is like a cell phone bill with the potential for charging for excess minutes. The latter is like buying a pre-paid phone card.
OS 2200 does not have a hierarchical file system as do most other operating systems. Rather it has a structured naming convention and the notion of container files called program files.
Files in OS 2200 are simply containers that may be addressed either by word offset in the file or by sector (28-word unit) offset in the file. The 28 words is a historical unit from an early mass storage device (the FASTRAND drum) that could hold 64 such units per physical track. Nonetheless, it is a fortunate historical accident. Four such 28-word units or 112 words occupy 504 bytes. With today’s mass storage devices all using 512-byte physical records, OS 2200 clients have almost all adopted some multiple of 112 words as their physical record size and database page size. I/O processors automatically adjust for the 504<->512 byte mapping adding 8 bytes of zeros on writes and stripping them off on reads of each physical record. OS 2200 handles applications that use sizes other than multiples of 112 words by indivisibly reading the containing physical records and writing back out the unchanged and changed portions with data chaining. Special locking functions guarantee indivisibility even when there are device errors and across multiple systems in a cluster.
File formats and other internal data structures are described in the Data Structures Programming Reference Manual[10].
File names take the form Qualifier*Filename(F-cycle) (e.g., "PERSONNEL*EMPLOYEES(+1)")[6]. Qualifier and filename are simply twelve-character strings used to create whatever naming structure the client desires. F-cycle is a number from 0 to 999 that allows multiple generations of a file. These may be referenced by relative numbers (+1) next or new cycle, (-1) previous cycle, (+0) current cycle. Leaving the cycle off defaults to the current cycle. Batch production runs that create new generations of files use this approach. The numbers wrap around after 999. Only 32 consecutive cycle numbers may exist at one time. Creating a (+1) deletes (-31).
Any file may be used as a program file. A program file contains elements which generally act as files. Element naming is Q*F(c).Element/version(e-cycle) (e.g., "PERSONNEL*PROGRAMS.TAXCALC/2008"). Element and version are twelve-character names used in any way a user desires. E-cycle is similar to f-cycle in that it represents a generation number but without the restriction to 32 concurrent cycles and the limit is 256K cycles. However, e-cycle only applies to text elements and each line in a text element is marked with the cycle numbers at which it was inserted and deleted. Elements also have a type and sub-type. The most commonly used types are “text” and “object.” The default element name of an object file is the same as the text file from which it was created. Generally, which one you mean is obvious from context. Where it is not, options select the appropriate type. Text elements also have sub-types that typically represent the programming language (e.g., “ASM”, “C”, “COB”, “FOR”).
An object element may be executed if it is a main program or linked with other object elements including a main program. The linking may be static or dynamic. A main program may be executed without pre-linking provided all required sub-programs are in the same program file, are system libraries, or are otherwise known. Rules may be included in a program file to direct the dynamic linker’s search for unfulfilled references. The linker may also be used to statically link multiple object modules together to form a new object module containing all instructions, data, and other information in the original object modules.
Omnibus elements may be used as data by applications or may serve to hold structured information for applications and system utilities. There is no assumed structure to an omnibus element.
For compatibility with earlier (basic mode) programming models, there are relocatable and absolute element types. Relocatable elements are the output of basic mode compilers. They may be combined by the basic mode static linker (@MAP – the collector) to form an “absolute” element which is executable.
OS 2200 implements a fully virtual file system. Files may be allocated anywhere across any and all mass storage devices. Mass storage is treated as a large space pool similar to the way virtual memory is managed. While contiguous space is allocated if possible, mass storage is treated as a set of pages of 8KB size and a file can be placed in as many areas of the same or different devices as is required. Dynamic expansion of files attempts to allocate space adjacent to the previous allocation, but will again find space wherever it is available. In fact, files need not even be present on mass storage to be used. The Exec and the file backup system are fully integrated. When file backups are made, the tape reel number(s) are recorded in the file directory. If space gets short on mass storage, some files are simply marked as “unloaded” if they have a current backup copy. If enough space can’t be found that way, a backup is started.
Any reference to an unloaded file will be queued while the file is staged back to mass storage. The whole system is automatic and generally transparent to users[11].
In general, the Exec does not provide access methods. Files are simply containers. Access methods are provided by the language run time systems and the database manager. The one exception is a fixed-block access method provided for high-volume transaction processing[12]. It has much less overhead than the database manager, but does participate in all locking, clustering, and recovery mechanisms.
When clients do want more explicit control over the location of files, they can use the “removable pack” concept. At one time these truly represented physically removable disk packs, and the operating system would automatically generate pack mount requests to operators as needed.
Today they are still used to place files, usually database files or transaction files, on one or more disk volumes. Files may still span multiple disk volumes, however, now the list of volume names is given when the file is created. Files that are on such volume groups are still backed up but are not subject to automatic virtual space management.
OS 2200 also provides a full implementation of the Common Internet File System (CIFS)[13]. CIFS implements the SMB protocol used by Microsoft servers and the UNIX/Linux Samba software. With CIFS OS 2200 appears to be both a file server and file client to other CIFS-compliant systems. This includes desktop PCs running Windows.
In order to maintain OS 2200 security two levels of protection are provided. First, OS 2200 files are not visible to the network until they have been declared as “shares” with a CIFS command. A specific privilege exists to control who may declare a share. The second level of control is that all access is still protected by OS 2200 security. Clients accessing OS 2200 via CIFS will either have to be automatically identified via NTLM or Kerberos or they will be presented with a query for their OS 2200 user id and password.
CIFS allows OS 2200 files to be presented in a hierarchical view. Typically the qualifier will appear as the highest level in the tree followed by filename, element name, and version. In addition, files may be stored on OS 2200 servers using the full Windows filename format. Windows applications will see OS 2200 as another file server. OS 2200 applications have APIs available to read and write files existing on other CIFS-compliant servers, such as Windows file servers, in the network. Text files are automatically converted to and from OS 2200 internal formats. Binary files must be understood by the application program.
The concept of subsystems and protected subsystems are central to the design of OS 2200. A subsystem is most analogous to a .dll in Windows. It is code and data that may be shared among all programs running in the system. In OS 2200 each subsystem has its own set of banks that reside in a separate part of the address space that cannot be directly accessed by any user program. Instead the hardware and the OS provide a "Gate" that may be the target of a Call instruction. See Unisys 2200 Series system architecture for more information.
The database managers, run time libraries, messaging system, and many other system functions are implemented as subsystems. Some subsystems, usually consisting of pure code, such as the run time libraries may be the direct target of a Call instruction without requiring a gate. These subsystems run in the user program's protection environment. Other subsystems, such as the database managers, consist of code and data or privileged code and may only be called via a gate. These subsystems may also have access control lists associated with them to control who may call them. More importantly, the gate controls the specific entry points that are visible, the protection environment in which the subsystem will run, and often a user-specific parameter that provides additional secure information about the caller.
OS 2200 security is an implementation of the DoD Orange Book B1 level specification[14]. OS 2200 first obtained a successful B1 evaluation in September, 1989. That evaluation was maintained until 1994. After that point, OS 2200 developers continued to follow development and documentation practices required by the B1 evaluation.
Central to a B1 system are the concepts of users and objects[15]. Users have identities, clearance levels, compartments and privileges. Objects require certain combinations of those for various types of access. Objects in OS 2200 consist of files, protected subsystems, devices, and tape reels.
The security profile of a user session includes the user identity, clearance level (0-63), compartment set, and set of allowed privileges. OS 2200 implements both Mandatory Access Control (MAC) and Discretionary Access Control (DAC) based on the Bell-La Padula model for confidentiality (no read up, no write down) and the Biba integrity model (no read down, no write up). For a run to read or execute a file, the run’s executing clearance level must be greater than or equal to the clearance level of the file, and the file’s clearance level must be 0 or within the clearance level range of the run; in addition, the run's executing compartment set must contain the file's compartment set. Because OS 2200 combines the Bell-La Padula and Biba model requirements, a run's executing clearance level and compartment set must exactly match those of a file to permit writing to the file or deleting it.
DAC associates an access control list with an object; the list identifies users and user groups that have access and defines the type of access that user or group is allowed (read, write, execute, or delete).
OS 2200 provides a fine-grained security mechanism based on the principal of least privilege. This principal demands that only the minimum privilege be granted necessary to perform the task required. Thus, OS 2200 has no “Super User” or “Administrator” concept. Rather it uses a large set of specific privileges which may be granted separately. Each privilege is associated with a specific authority.
The security officer or the user who creates an object may create an access control list for that object. The default is that the object is private to the creating user.
Because the full set of B1 controls is too restrictive for some environments, system administrators can configure servers by choosing which controls to apply. A set of security levels from Fundamental Security through Security Level 3 serves as a starting point.
When users log on to the system, they identify themselves and optionally select the clearance level and compartment set they will use for this session.
OS 2200 offers a flexible authentication system. Multiple authentication mechanisms are supported concurrently. Client- or third party-written authentication software may also be used. Standard authentication capabilities include:
The last two permit the use of biometrics, smart cards, and any other authentication mechanism supported by those technologies.
OS 2200 provides encryption for data at rest through Cipher API, a software subsystem that encrypts and decrypts caller data using FIPS-certified implementations of the AES and 3DES algorithms. Cipher API also supports the use of a hardware accelerator card for bulk data encryption.
CPCOMM provides SSL/TLS encryption for data in transit.
OS 2200 also supports encrypting tape drives, which provide encryption for archive data.
OS 2200 systems may be clustered to achieve greater performance and availability than a single system. Up to 4 systems may be combined into a cluster sharing databases and files via shared disks. A hardware device, the XPC-L, provides coordination among the systems by providing a high-speed lock manager for database and file access.[16]
A clustered environment allows each system to have its own local files, databases, and application groups along with shared files and one or more shared application groups. Local files and databases are accessed only by a single system. Shared files and databases must be on disks that are simultaneously accessible from all systems in the cluster.
The XPC-L provides a communication path among the systems for coordination of actions. It also provides a very fast lock engine. Connection to the XPC-L is via a special I/O processor that operates with extremely low latencies. The lock manager in the XPC-L provides all the functions required for both file and database locks. This includes deadlock detection and the ability to free up locks of failed applications.
The XPC-L is implemented with two physical servers to create a fully redundant configuration. Maintenance, including loading new versions of the XPC-L firmware, may be performed on one of the servers while the other continues to run. Failures, including physical damage to one server, do not stop the cluster, as all information is kept in both servers.
OS 2200 operations is built around active operators and one or more consoles. Each console is a terminal window, part of which is reserved for a fixed display that is frequently updated with summary information about activity in the system.[17]
The rest of the console is used as a scrolling display of events. When a message is issued that requires an operator response, it is given a number from 0 to 9 and remains on the display until it is answered. Tape mount messages do scroll with other messages but will be repeated every two minutes until the tape is mounted.
Operations Sentinel[18] is used for all OS 2200 operations. OS 2200 consoles are simply windows within an Operations Sentinel display. There may be as many display PCs as desired. Remote operation is typical. Operations Sentinel supports any number of ClearPath, Windows, Linux, and UNIX systems.
An auto-action message database is released with the product[19]. This database allows Operations Sentinel to recognize messages. Scripts may be written to automatically respond to messages that require a response, hide unwanted messages, translate them to other languages, create events, etc. Full dark room operation is used by some clients. At most they will have Operations Sentinel displays at remote locations monitoring the system and creating alerts when certain events occur.
Administration of OS 2200 systems is performed using a wide variety of tools, each specialized to a particular area of the system. For example, there is a tool used for administering the transaction environment that allows new transaction programs to be installed, specifies all the necessary information about them, changes the queuing structure, priorities, and concurrency levels, and so on[20].
Other tools are specific to the Security Officer and allow creation of users, changing allowed privileges, changing system security settings, etc.[15], [21].
Most of the tools have a GUI interface although some do not. All provide a batch stored file interface where all actions are specified in the control stream. This allows scripting any and all of the administrative interfaces from either local sites, maybe based on time of day or other events, or from remote sites. Unique privileges are required for each administrative area.
Application groups are a logical construct consisting of an instance of the Universal Data System (UDS[22]), an instance of the message queue subsystem, and some set of transactions. Each application group has its own audit trail. OS 2200 supports a maximum of 15 application groups in a system.
The notion of application group corresponds to what is often called “an application.” That is, a set of programs and data that represent some larger unit of connected processing. For example, an application group might represent an airline system. Another application group might represent the corporate finance system. Or, application groups might represent instances of the same application and data models, as in bank branches. The important thing is that each application group has its own environment, sessions, recovery, etc.
Application groups may be started, stopped, and recovered independently.
Application groups do not have their own accounting and scheduling rules. Transactions in multiple application groups may share the same priorities and have interleaved priorities. This permits the site to control the relative priorities of transactions across the entire system.
The Unisys History Newsletter contains articles about Unisys history and computers. In addition to all of the Unisys History Newsletters there are links to other sites.
Most of the historical archives of Unisys are at the Charles Babbage Institute at the University of Minnesota and at the Hagley Museum and Library in Delaware. The Charles Babbage Institute holds the archives from ERA, some early Remington Rand archives from Saint Paul, MN, and the Burroughs archives. The Hagley Museum and Library holds the bulk of the Sperry archives.